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REGIONAL FARE COORDINATION SYSTEM 
CHANGE ORDER NO. 10 

CONTRACTOR: ERG Transit Systems (USA) Inc. 

CONTRACT NUMBER: 229944 

This Change Order to Contract #229944 (“Change Order”) is executed as of_, by and between 

ERG Transit Systems (USA) Inc, a California corporation and wholly owned subsidiary of ERG Limited, 
an Australian corporation, (hereinafter referred to as the “Contractor”) and each of the following seven 
public transportation agencies (hereinafter referred to individually as an “Agency" or collectively as the 
“Agencies’ 1 ): 

1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area ("Pierce Transit") 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett (“Everett”) 

7. State of Washington, acting through the Washington State Department of Transportation, 
Washington State Ferries Division ("WSF") 

Background 

A. Effective April 29,2003, each of the Agencies and the Contractor entered into Contract #229944 
(“Contract”) to implement a Regional Fare Coordination System ("RFC System") to establish a 
common fare system utilizing smart card technology. The Contractor is responsible for the 
development, implementation, operation and maintenance of the RFC System as specified in the 
Contract. 

B. The Agencies and the Contractor desire to execute this Change Order No. 10 to revise the Contract 
to reflect no-cost approved decisions that have been made through the Request for Information 
(RFl) process and workshops and other communications. The decisions are reflected in approved 
design documents as appropriate. 
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Agreements 


The Agencies and the Contractor hereby agree to the following changes to the Contract: 

1.0 Division I, II, and III Changes 

1 . 1 Contract Sections I, II. and III are revised to reflect no-cost changes approved by the Agencies 
and the Contractor through the RFI process, workshops and other communications as 
described in the following table: 


RFI No. 

Item 

No. 

(D 

Description of Change 

Contract Section 

Revised Contract Language 

SEA-00664 

ERGRFI 

00155 

21 

Replace stored rides throughout the 
contract with Multiride. 

All changes identified in the RFI and 
agreed to by the Agencies have been 
incorporated. This section has then 
been made consistent with DR 101 as 
approved at PDR. 

Also correct the numbering of 2.1.1.2 

10 2.1.1.3 Customized Products. The 
contract has duplicate section 
numbers for Electronic Voucher and 
Customized Products. 

3.1-76.4.11 

6.11-2.1.1.2 

6.11- 2.1.1.33 

6.11- 2.2.2.3 (a) and (b) 

6.11- 4.2.2 (h) and 0) 

6.11- 5.2.3.3 (d) 

6.11- 9.2 

6.11- 11.1.6.1 

6.111- 2.4.3 

6.111- 2.4.3.1 

6.111- 2.4.3.3 

6.111- 2.4.3.4 

6.111- 2.4.3.5 

6.111- 2.4.3.7 

6.111- 9.2 

6.111- 10.2.1.2 

6.11110.2.1.4 

6.111- 10.9 

6.111- 13.3.2.2 

Exhibit 9 II 

Exhibit 9 XIII 

See Change Order 10 - Attachment A 

See Change Order 10 - Attachment 1 

See Change Order 10 - Attachment 1 

See Change Order 10 - Attachment J 

See Change Order 10 - Attachment K 

See Change Order 10 - Attachment L 

See Change Order 10 - Attachment M 

See Change Order 10 - Attachment N 

See Change Order 10 - Attachment B 

See Change Order 10 - Attachment B 

See Change Order 10 - Attachment B 

See Change Order 10 - Attachment B 

See Change Order 10 - Attachment B 

See Change Order 10 - Attachment B 

See Change Order 10 - Attachment O 

See Change Order 10 - Attachment P 

See Change Order 10 - Attachment P 

See Change Order 10 - Attachment P 

See Change Order 10 - Attachment P 

See Change Order 10 - Attachment F 

See Change Order 10 - Attachment R 

SEA-00202 

ERGRFI 

00041 

3 

Clarify that the signature process 
defined does not apply to Web 
enrollment. 

6.11-1.2.1 

See Change Order 10 - Attachment C 

SEA-00547 

ERGRFI 

00132 

16 

Update Figure 11-1.1 to include Walk 

In Center and add a section for Set 
up and configuration of Auto 

Revalue. 

Add column for walk in center and 
identify required functionality as 
agreed with Agencies in this RFI and 
then modified somewhat in the 
review of DR 1 Customer Service at 
PDR document workshops 

6.11-1.2.1 

Figure 11-1.1 

See Change Order 10 - Attachment C 

SEA-00203 

ERGRFI 

00042 

Superceded 

by 

SEA-00545 
ERG RFI 

156. 

4 

Change Figure 11-11.1 to reflect fare 
transactions will be available via 
separate link on the primary 
customer page and specify amount 
of transaction history to be displayed 

Add (30 days) to transaction history 
line and clarify that fare transactions 
will be available via a separate link 
on the primary customer page 

6.11-1.2.1 Figure 11-1.1 

See Change Order 10 - Attachment C 

SEA-00684 

ERGRFI 

00159 

22 

Update Figure 11-1.1 to add the ability 
to report a lost or stolen linked card" 
at the RFCS website and to report a 
general issue. 

6.11-1.2.1 Figure 11-1.1 

See Change Order 10 - Attachment C 
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RFI No. 

Item 

No. 

(D 

Description of Change 

Contract Section 

Revised Contract Language 

SEA-00200 
ERG RFI 
00039 
SEA-00448 
ERG RFI 
00158 

2 

Clarify that PIN or password does not 
apply to anonymous card holders. 

6.11-1.2.5 (k) 

Customers with linked cards and institutions shall be able to 
establish a personal identification number (PIN) or 
password for access to account information. 

CT Beta 

Test 

29 

Change CT Beta Test from 1 to 2 
sites. 

6 . 11 - 11 . 1 . 2.1 (a) 

(a) The Beta Test shall consist of equipment installed 

at two bases, to be specified by the Contract 
Administrator, and must include CT s CSO to test 
the integration of the CT point of sale terminal 



—--- 


with the new system. 

None 

31 

Remove the contractual reference 
that is in error. 

6.11-11.4.6.3(a) (lx) 


SEA-00798 
ERG RFI 

24 

Add subsection to clarify payment 
options for Institutional Voucher 

6.11-2.2.1 (i) 

See Change Order 10 - Attachment S 

00189 


proqram 



SEA-00579 

ERGRFI 

00152 

ERG RFI 

235 

20 

Change the timing of card update 
download to the Revalue Network. 

Change (a) from one (1) working day 
to “sixty (60) workmq days.:" 

6.11-4.3 (d) and 6.11-5.3 
(0 

6.114.3 

See Change Order 10 - Attachment H 

SEA-00217 

ERGRFI 

00052 

6 

Clarify revenue sharing processing 
rules. 

6.11-5.2.2(1) vii 

(1) vii. The Contractor shall calculate the daily 
settlement due each AgencySpecific revenue sharing 
processing rules shall be provided to support this 
calculation, but at a minimum, the following shall apply: 

Revenues are settled based on number and type of 
transactions. 

- For fare media (including e-purse) that are valid at 
more than one Agency, the Agencies will defer revenue 
for one month (or whatever timeframe is considered 
practical) and use actual data to adjust/settle the 
amounts. 

-Upon sale of all multi-Agency passes or passes of 30 
days or less in duration (l.e. weekly or daily), pass 
revenue will be distributed at the end of the pass period 
based upon actual usage. 

-For monthly multi-Agency, period (multi-month) passes, 
revenue will be distributed in equal monthly amounts 
(i.e. 1/12 for annual, 1/3 for quarterly) based upon a pre¬ 
defined allocation formula to be supplied by the 

Agencies. 

For fare media that are valid exclusively at one agency, 
or where the amount received by an Agency is a flat 
(predetermined) amount, the Agencies will receive all 
revenues on the day that the purchase transaction is 
complete 

SEA-00205 

ERGRFI 

00044 

5 

Add definition of Expire Gap for 
transactions 

6.H-5.2.2 (k) 

(k) Contractor shall administer a claims fund held in an 
account designated by the Contract Administrator (DR 

5.03). The claims fund shall be used to settle revenue for 
lost transactions or transactions that otherwise cannot be 
reconciled. Transactions will be considered expired if they 
have not cleared by the end of the expiration period and 
funds will then be transferred into the claims fund. 

SEA-00218 

ERGRFI 

00053 

7 

Clarify that commissions will be 
handled outside of the 

Clearinghouse. 

6.11-9.1 (b) 

(b)The Agencies shall maintain and manage contractual 
agreements with retail outlets, and shall be responsible for 
the establishment of the commission structure. These 
commissions will be handled by the Agencies outside of the 
Clearinghouse. 

SEA-00428 

ERGRFI 

00085 

11 

Clarify that the need for duplicate 
receipts is at the time of sale. 

6.111-11.1 (i) 

(i).Provide a transaction history on each fare card by 
accessing the clearinghouse database, and ability to print 
duplicate receipts at the time of the sale. 
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RFI No. 

Item 

No. 

(1) 

Description of Change 

Contract Section 

Revised Contract Language 

SEA-00292 

ERGRFI 

00130 

15 

DAC and BOC Hardware 
configuration changes as discussed 
and agreed to with the Agencies. 
Change hardware requirements to 
reflect revised configuration as 
agreed with Agencies and as 
reflected in accepted PDR versions 
of DR 109 and DR 110. 

6.111-12.4.1 (a) 

See Change Order 10 - Attachment G 

SEA-00544 

ERGRFI 

00124 

SEA-00570 

ERGRFI 

00125 

13 

Data Communications for the DAC 

6111-12.7.2 

12.7.2 Data Communications 

(b) All batches shall be tagged with DACS header 
information including as a minimum DACS ID, date stamp, 
and time stamp. 

SEA-00600 

ERGRFI 

00139 

18 

Clarification that Commercial account 
will be considered a product. 

6.lll-16.2(c) 

16.2{ c)At the point of use. the RFCS shall confirm that the 
Commercial Account Card and identification number are 
valid. Invalid cards shall be rejected, and the Commercial 
Account product on the card shall be rejected as payment 

ERG 

uncovered 

discrepancy 

In contract 
review 

28 

Remove incorrect reference in 6.111- 
16.3 -Section refers to 6.11-10.2.5.2 
which does not exist. 

6.111-16.3 

6.111-16.3 On-Call Maintenance Service Levels 

In addition to the requirements described in Exhibit 15 Post 
Warranty On-Site Maintenance, the Contractor shall meet 
the following requirement: 





(a) For remote ferry locations (i.e.. Anacortes. San Juans, 
Port Townsend and Keystone), Contractor shall arrive 
on-site within 4 hours rather then 90 minutes. 

SEA-00612 

ERFRFI 

00167 

23 

Card Memory Storage Capability - 
The Agencies have accepted the 
DESfire as the primary fare card for 
the RFCS system. This results in 
some required changes to the 
memory requirements as discussed 
initially in this RFI but further in DR 

101 review workshops. 

6.111-2.4 2 

2.4.2 Card Memory Storage Capacity 

At a minimum, the memory storage capacity shall be 
sufficient to support all RFCS functions and shall ensure 
that the card has sufficient memory to store at least two 
other non-transit applications 

(a) The Contractor shall choose and specify the memory 
capacity of the fare card given the requirements specified 
herein and according to the Contractor s analysis of those 
data and system requirements including the anticipated 
addition of RFCS and non-RFCS applications to the card. 

(b) The Agencies reserves the right to use the remaining 
memory on Agency issued fare cards for purposes not 
identified at time of Contract award. 

SEA-00636 

ERGRFI 

00140 

19 

Move "Customer Zone Fare 

Preference Preset field from Base 
segment to Agency Data segment as 
agreed to by the Agencies. 

6.111- 2.4.3.1 

6.111- 2.4.3.2 

See Change Order 10 - Attachment B 



Move this field from Base Segment 
(6.111-2.4.3.1) to Agency Segment 
(6.111-2.4.3.2) to allow this field to be 
used only by Agencies requiring this 
field. 

2.4.3. Add “(non-disposable)' to this 
sections first sentence. 



SEA-00737 

ERGRFI 

00198 

25 

Combine fare category type and 

RRFP type into a single passenger 
type in the data to be stored on the 
fare card. 

6.111-2.4.3.1 

See Change Order 10 - Attachment B 



Remove Fare Category Type 

Indicator and RRFP Type Indicator 
from Section 6.111-2.4.3.1 and add a 
new data field - Passenger Type. 
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RFI No. 

Item 

No. 

(1) 

Description of Change 

Contract Section 

Revised Contract Language 

SEA-00564 

ERGRFI 

00133 

17 

Remove Ride Qualification Code 
from Regional Card Data. 

Remove this field from table in 

Section 6.111-2.4.3.5. 

6.111-2.4.3.5 

See Change Order 10 - Attachment B 

SEA-00123 

ERGRFI 

0032 

1 

Remove Entry Location 2 and 3 from 
Ride History- Data Fields - no longer 
required. 

6.111-2.4.3.6 (b) 

See Change Order 10 - Attachment B 

UW Request 

27 

Remove the requirement for a bar 
code on the UW card. 

Remove Section 2.7.2.3 in its entirely 

6.111-2.7.2.3 


SEA-00411 
ERGRFI 

00077 

RFCS RFI 

017 

9 

Update the structural features of the 
FTP enclosures. 

6.111-3.4.2(3) 

3.4.2 Structural Features 

(a) The finish shall be orbital finished stainless steel, unless 
specified otherwise or approved by the Contract 

Administrator The following changes have been approved 
by the Contract Administrator: 

1) The DDU and OB FTP will be manufactured from 
injected molded plastics 

2) The finish of the SAFTP will be non-ferrous bead blasted 

(b) Provisions shall be incorporated to clear any liquids that 
may enter the device or condensation that may develop. 

SEA-00925 

ERGRFI 

00199 

26 

Modify key or button life on DDU to 1 
million actuations. 

6.IH-6.3 ( c) 

(c) All keys or buttons shall have a minimum 10 year 
service life in normal operation, regardless of number of 
actuations. In the event that a key or button fails before the 

10 year service life, it shall be replaced at no cost to the 
Agencies per Section 4.1 of Exhibit 14 of the Contract 
provided such failure does not constitute an Agency 
responsibility as defined in Section 4.2 of Exhibit 14. 

SEA-00449 

ERG-RFI 

088 

12 

Make changes associated with 
provision of Unitech PFTP 

Updated Section 6.111-8.5 (b), Figure 
111-8.1 and Section 6.111-8.2 <g) as 
noted in RFI and agreed to by WSF. 

6.111- 8.2 (g) 

6.111- 8.5(b) 

Figure 111-8.1 

See Change Order 10 - Attachment E 

SEA-00399 

ERG-RFI 

071 

8 

Key Button Life- 

6.lll-9.4.3(a) 

9.4.3 Keypad (zone selection buttons) 

The keypad/zone selection buttons shall meet the following 

requirements: 

(a) All keys or buttons shall have a 10 year service life in 
normal operation, regardless of number of actuations. 

In the event that a key or button falls before the 10 
year service life, it shall be replaced at no cost to the 
Agencies per Section 4.1 of Exhibit 14 of the Contract 
provided such failure does not constitute an Agency 
responsibility as defined in Section 4.2 of Exhibit 14. 

(b) The keypad shall be designed to be water and liquid 
resistant. 
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RFI No. 

Item 

No. 

(D 

Description of Change 

Contract Section 

Revised Contract Language 

SEA-00572 

ERGRFI 

00129 

14 

Clarify approach to meeting the 
requirements related to remote 
monitoring of the SAFTP. 

6.111-9.5 (b) 

6.111-9.5 Data Exchange Requirements - Stand Alone 

FTP 

(a) SAFTPs shall include a communications module for 
connecting to a DAC and the capabilities to be 
connected to a PC through a standard port. 

(b) The Contractor shall provide the software for a PC that 

allows the use of a PC keyboard to operate the 

SAFTP and PC monitor to display the card data. This 
connection from the SAFTP will be provided via an 
auxiliary serial port that is sealed within the SAFTP 
mounting pole or wall cradle and accessible at a 
remote location within visual range of the SAFTP. 

(c) SAFTPs supplied for WSF shall include a standard 

serial interface, designed for future connection to 
WSF's new point of sale system. The Contractor 
shall provide an Interface Control Document (DR 
106.02) fully describing this interface. 

(d) SAFTPs and associated DACs installed at Sound 

Transit rail stations shall communicate through 

Sound Transit's existing TVM communications 
network 

None 

30 

Reverse delivery sequence of CDRL 

22 and CDRL 23. 

Figure 6.11-11.6 

See Change Order 10 - Attachment T 


Note: (1) Identifies the contract change item number according to the “RFI/Contract Change Matrix" in the ERG 
Change Request SEA-01306. 


1.2 The Agencies and the Contractor hereby agree to Amendment 9 without further execution, a 
copy of which is attached hereto as "Change Order No. 10 - Attachment A.' 

1.3 All other no-cost decisions not identified in this Change Order No. 10 will be reflected in 
subsequent Change Orders. 

2.0 Other Terms and Conditions 

Except as expressly amended by this Change Order, the Contract remains in full force and effect. All 
other provisions of the Contract not referenced in this Change Order No. 10 shall remain in effect unless 
modified in other executed Amendments and Change Orders. 
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IN WITNESS WHEREOF, the parties hereto have executed this Change Order No. 10 to Contract 
#229944 as of the date set forth below its signature. 


ERG Transit Systems (USA) Inc. 

The Agencies 

Bv: 

Its: ' ?M>J MtJ AC£rC- 

Bv: ^ , . 

Their ('MrhrAA't'AslMM 51 YATvL- 

Date: 2&-TW-05'' 

On behalf qf the Agencies 

Date: 

Central Puget Sound Regional Transit 
Authority 

City of Everett 

By: 

Its: 

Date: 

By: 

Ray Stephanson, Mayor, or His Designee 

Date: 

King County 

ATTEST: 

By: 

Sharon Marks, City Clerk 

Date: 

By: 

Its: 

Date: 

APPROVED AS TO FORM: 

Pierce County Public Transportation 

Benefit Area 

By: 

James D. lies, City Attorney 

Date: 

Kitsap County Public Transportation 

Benefit Area 

By: 

Its: 

Date: 

By: 

Its: 

Date: 

Washington State Ferries, Washington 

State Department of Transportation 

Snohomish County Public 

Transportation Benefit Area 

By: 

Its: 

Date: 

By: 

Its: 

Date: 
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Tabic of Attachments 


A 

Amendment 9 for Div. 1 changes 

B 

6.111-2.4.3 

C 

6.11-1.2.1 

D 

left blank due to move to different CO the changes to remove 

LonWorks port 

E 

6.111-8.1, 8.2 and 8.5 

F 

Exhibit 9 II 

G 

6.111-12.4.1 

H 

6.11-4.3 and 6.11-5.3 

1 

6.11-2.1.1 

J 


K 

6.11-4.2.2 

L 

6.11-5.2.3.3 

M 

6.11-92 

N 

6.11-11.1.6.1 

0 

6.111-9.2 

P 

6.111-10.2.1.2 and 10.2.1.4 and 10.9 

Q 

left intentionally blank to move changes to 6.111-13.3 2.2 to upcoming 
Reporting CO 

R 

Exhibit 9 XIII. 

S 


T 

Figure 11-11.6 
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Change Order No. 10 - Attachment A 


Amendment Nine to the Contract for the Design, Implementation, Operation and Maintenance of 

the Regional Fare Coordination System 

This Amendment Nine to the Contract for the Design, Implementation, Operation and Maintenance of the 
Regional Fare Coordination System is incorporated into Contract Change Order No. 10. 

Recitals 


A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract #229944 
(“Contract”) to implement a Regional Fare Coordination System (“RFC System”) to establish a 
common fare system utilizing smart card technology. The Contractor is responsible for the 
development, implementation, operation and maintenance of the RFC System as specified in the 
Contract. 

B. The Agencies and the Contractor desire to enter into this Amendment Nine to revise certain areas 
of Division I of the Contract to align the Contract with no-cost decisions agreed by the Agencies 
and ERG through the Request for Information (RFI) process, workshops, and other 
communications. 

NOW, THEREFORE, in consideration of the mutual covenants contained herein and in the Contract, the 
sufficiency of which is hereby acknowledged, each Agency and the Contractor hereby agree to amend the 
Contract as follows: 

Section 1.0 

Section 3.1-76.4.11 of the Contract is hereby amended to read as follows: 

76.4.11 Clearinghouse Services 

a. Prices for Clearinghouse Services shall remain as specified in Exhibit 9, Section XIII for 
three (3) years after Full System Acceptance. Thereafter, the Fixed Monthly Fee in said 
Exhibit shall be subject to annual adjustment upward or downward, effective on the 
anniversary of the first day of the first complete month following Full System Acceptance, 
in accordance with the formula set forth in Section 76.6 or the Price Warranty in Section 
3.1-62, whichever shall result in the lowest prices. 

b. There are two types of transaction fees, 1) General, and 2) 3' d Party Revalue. The 
General Transactions consists of E-Purse, Pass and Multi-ride, Payment and Revalue 
transactions and the fee shall be determined according to the total number of transactions 
generated by the Agencies’ transit application (which may include transactions generated 
by non-Agency card acceptors) processed in a month as specified in Exhibit 9, Section 
XIII and shall be applied to each such transaction. The 3 rd Party Revalue Transaction Fees 
shall be those revalue transactions performed only through 3 rd party retailers. 

c. The “Fixed Monthly Fee” and ‘Transaction Fees” (both General and 3 rd Party Revalue) 
will be payable on a monthly basis. 


Section 2.0 

All other provisions of the Contract not referenced in this Amendment Nine shall remain in effect. 
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Change Order No. 10 - Attachment B 


2.4.3 Data on the Regional Fare Card 

The following minimum data segments shall be provided on the "normal (noi 
disposable) fare" card (DR 101.05): 

(a) Base Segment 

(b) Agency Data 

(c) RFCS Stored Value Purse 

(d) Pass Products (zero or more) 

(e) Multi-ride Products (zero or more) 

(f) Ride History 

(g) Revalue History 

The way data is stored on a fare card is not specified. 

2.4.3.1 Base Segment (One Per Card) 


The base segment shall consist of the following minimum data fields: 


Data Field 

Comments 

Card Serial Number 

Regional Fare Card-assigned number 

Card Expiration Date 

Based on life of card 

Passenger Type Indicator 

Adult. RRFP senior. RRFP disabled, youth or other 
category 

Passenger Vehicle Type Indicator 

Defines the default vehicle type for WSF vehicle ferry 
travel (up to 20 different types; 7 types estimated 
initially) 

Passenger Type Expiration Date 

Required for temporary disabled 

Cardholder Birth Date 

Optional for RRFP cards or youth 


2.4.3.2 Agency Data (Optional Data Per Agency) 

Agency-specific data that needs to be stored on the fare card (not required by all 
agencies). 

(a) This feature shall be transparent to the customer. 

(b) The Agency Data shall consists of the following minimum data fields: 
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Data Field 

Comments 


Loyalty meters (as described in the PDR document) will not 
be stored on the fare card. 


Loyalty meters (as described in the PDR document) will not 
be stored on the fare card. 


Loyalty meters (as described in the PDR document) will not 
be stored on the fare card. 


Loyalty meters (as described in the PDR document) will not 
be stored on the fare card. 


Loyalty meters (as described in the PDR document) will not 
be stored on the fare card. 


Loyalty meters (as described in the PDR document) will not 
be stored on the fare card. 

Customer Zone or Route Fare 
Preference Preset 

Parameter that indicates the customer's preference for 
number of zones of travel in a multi-zone system (e.g. 1,2 
or 3), or WSF route designated by an origin-destination pair. 
Functionality to be included but implemented per Agency 
policy. 


2.4.3.3 RFCS Stored Value Purse (One Per Card) 

If a card has an RFCS stored value purse, monetary value will be added by the add 
fare process and subtracted through fare calculations. The RFCS Stored Value 
Purse shall consist of the following minimum data field: 


Data Field 

Comments 


To be stored in CD 

Remaining Value on Card 

Current stored value remaining on card. 


2.4.3.4 Pass Products 

A card may be loaded with zero or more passes. Only one pass of the same type 
may be currently active for an Agency. The Pass shall consist of the following 
minimum data fields: 


| Data Field | Comments 

Start Date of Pass 

First date for rides 

Expiration Date of Pass 

Last date for rides 

Type of Pass 

e.g. Day Pass, Monthly, Employer, Campus, Puget Pass 


2.4.3.5 Multi-Rides 

“10 Day Passes (Trips or Rides)” will be stored as Multi-ride Products, rather than 
10 individual ride products. This provides additional flexibility for the agencies 
(allowing 20 ride products, for example) as well as requiring less storage space on 
the card 

A card may be loaded with one or more blocks of stored rides, or trips, in the form 
of multi-ride products. 

(a) The fare card shall include capacity for at least one multi-ride product for 
each of the participating Agencies. 
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(b) Only one multi-ride product of the same type may be currently active per 
Agency. Multi-ride products on the card shall be in addition to any active 
passes for the Agency. 

(c) Multi-ride products may be specific to one Agency, or valid across multiple 
Agencies. 

(d) Each multi-ride product shall include the following minimum data fields: 


Data Field 

Comments 

Agency 

Agency who issued multi-ride product 

Remaining Rides 

Number of rides remaining in the multi-ride product 

Expiration Date 

Latest date, after which the product is no longer valid 


2.4.3.6 Ride History (Last Ten Rides) 

•"Ride History" for all Agencies will be stored in a single 10-record transaction ride 
log. Each time a card is tagged for a new ride, a record is created and the oldest 
record shall be purged. 

(a) The card shall have sufficient capacity to store the last ten (10)_transactions 
system wide. 


(b) The Ride History shall include the following minimum data fields: 


Data Field 

Comments 

Agency Providing Service 

Agency providing ride 

Route/Run/Trip 

Route, run, and trip code as applicable to Agency 

Entry Transaction Location 1 


Ride date 


FTP Number 

FTP ID number 

Time of Transaction 


Amount of Transaction 

Amount decremented from stored value of the card for current 
ride or transfer 

Transaction Code 

Such as: Ride, Reversal, Transfer, Short-payment (fare), 
Upgrade Fare, Exception, including any combination thereof 
(for example, pass transaction with stored value upgrade). 

Terminal Exit Transaction 

(Optional) exit FTP ID number 

Time of Exit 

(Optional) 

Exit Transaction Location 



2.4.3.7 Revalue History (Last Five Value Adds) 

"Revalue History" for all Agencies will be stored in a single, five-record revalue 
log. Same as the ride history, each time a card is revalued with a new value or pass, 
a revalue record is created and the oldest revalue record is purged. 

The Revalue History shall include the following minimum data fields: 
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Change Order No. 10 Attachment C 


Section 6.11-1.2.1 Customer Service 

The Contractor shall provide the equipment and services to support first and seco 
service activities as listed in Figure 11-1.1. 


Figure 11-1.1 Customer Service Activity Summary 
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* Revalues handled through the Call Centers, Mail Centers, and Internet will be downloaded to the revalue 
network. 

** The Internet website will be operated by the Contractor on behalf of the Agencies. 

*** Fare transactions should be available through a separate link on the primary customer page 
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Change Order No. 10 - Attachment E 


6.111-8.1 Subsystem Description - Portable FTP 

The Contractor shall provide portable FTPs for Agencies that have a need for a portable card 
reading and transaction processing device. 

The Portable FTP (DR 105) shall be a handheld, ruggedized unit operated by Agency personnel to 
process RFCS transactions in a mobile or portable environment. The PFTP will be powered by a 
rechargeable battery that can be recharged by placing the unit in a cradle or by a 12VDC adapter 
cable for in-vehicle use. 

The PFTP shall be supplied in two configurations: 

• Asa limited function, verifier only PFTP (DR 105.01) for Sound Transit proof of payment fare 
inspection. The unit shall be light, have low power consumption, and be able to conduct fare 
verification with minimal operation by the fare inspector. 

• A full-function PFTP (DR 105.02) for agencies such as WSF and Kitsap Transit, and 
potentially for paratransit and vanpool applications. 

The Portable FTP (PFTP) shall, at a minimum, consist of the modules listed in Figure 111-8.1. 


Figure 111-8.1 

PFTP CONFIGURATION SUMMARY 


Modules 

Portable FTP 

Central Processing Unit 

X 

Contactless Card Interface 

X 

Customer Display/Indicator 

X 

Charger/Cradle 

X 

Communications Interface(s) 

X 




“X” denotes module required by Contract 

6.111-8.2 Functional Requirements - Portable FTP 

The following functional requirements supplement those stated in Section 6.111-3.2. 

(a) Log-on from Agency personnel shall occur via a log-on smart card or through a 
built-in PFTP keypad. 

(b) For Washington State Ferries, the operator shall be able to select a destination and 
associated fare basis through the portable FTP keypad. 

(c) Except as noted in (e), the PFTP shall require no interaction other than the tag of a 
card within an Agency-configurable timeout period to perform card inspections. 
The timeout period shall automatically reset in the event of any of the following: 

i. The card inspection mode of the PFTP has been selected 

ii. Inspection mode is reactivated by the inspector after a timeout. 
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iii. A previous inspection has been completed 

(d) The verifier-only PFTP shall record inspection counts by fare category, fare type, 
operator ID, and time segment. 

(e) The PFTP shall allow the operator to override a default fare transaction (e.g. to pay 
for multiple fares from a single card, or to pay a fare other than the default). 

(f) The full function PFTP shall perform all functions of the verifier, plus, Agency 
personnel shall be able to: 

i. Determine card balance, number of stored rides on the card, or the 
existence of a pass. 

ii. Provide historical information to the Cardholder by scrolling through 
the transaction history of the last ten transactions stored on the card. 

(g) PFTPs for WSF applications shall include the ability to support an external printer, 
connected through either through the USB port or through a Bluetooth module 
inserted in the expansion slot. 


6.111-8.5 Data Exchange Requirements - Portable FTP 

Data exchange requirements described in Section 6.III-3.6.1 (a) are replaced by the 
following: 

(a) The verifier-only PFTP shall communicate with the DACS through a serial 
interface to the PFTP cradle. Subject to communications availability, the 
PFTP shall be able to share the same DACS as the Stand Alone FTPs 
installed at Sound Transit rail platforms. 

(b) The full function PFTP shall include the following communications ports, 
configurable by application: 

i. A serial communications port for direct connection or 

connection through a cradle to the DACS or an external modem, 

iii. A PCMCIA or other industry standard slot for connection of an 
802.11 client adapter, Bluetooth module for use with an external 
modem or printer, or other wireless communications device. 

(c) The full function PFTP shall be supplied with the 802.11 client adapter, 
CDPD modem, or other wireless communications device as required (DR 
104.05). 

(d) All communications shall be automatically initiated and completed. 
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Change Order No. 


10 - Attachment F 
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Change Order No. 10 - Attachment G 


6.111-12.4 Physical Requirements - Data Collection System 
12.4.1 Data Acquisition Computer 

(a) The DACS shall consist of standard PC components with minimum 
requirements as follows: 


Component 

Requirements 

CPU 

Intel Pentium 4 or Xeon, operating at >1.5 
GHz. 1U or 2U rack configuration 



Network Interface Card 

10/100 Mb/s Ethernet NIC 



RAM 

>512 Mb 



Hard Drive 

>40Mb, 7200 RPM 

CD ROM 

>48x 

Removable Media 

CD R/W with software to write large data 
files across multiple CD's 

Operating System 

Windows-based (NT, 2000, 2003, XP 
Professional) 


(b) The applications shall be programmed in high order languages such as 
JAVA, Visual Basic, or C++ and distributed objects. 

(c) Equipment will be installed in a secure location. 

(d) Each DAC shall have sufficient hard disk space to hold a minimum ninety 
(90) days of transactions. 
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Change Order No. 10 - Attachment H 


6.11-4.3 Performance Requirements 

(a) The Contractor shall initialize and distribute cards within sixty (60) working 
days of request. 

(b) The Contractor shall implement quality assurance steps which ensure the 
accuracy of information stored on the card and in the database. Quality 
assurance steps are subject to approval by the Contract Administrator. 

(c) Contractor shall track and manage card failure rates per the requirements of 
Section 6.III-2. 

(d) All card updates shall be transmitted to the revalue network within twenty 
four (24) hours and to the data acquisition systems within twelve (12) hours 
of recording of the transaction by the clearinghouse system. 


6.11-5.3 Performance Requirements 

(a) The batch interface shall have a minimum 99% availability 24 hours a day, 7 
days a week, per the availability formula contained in Section 6.111-1.5.2. 

(b) The on-line interface shall have a minimum 99% availability 24 hours a day, 7 
days a week, per the availability formula contained in Section 6 111-1.5.2. 

(c) Revenue shall be reconciled and settled with 100% accuracy. 

(d) Financial settlement shall be the next business day after transactions are 
uploaded to the clearinghouse system. 

(e) Daily reports shall be available by 8 a.m. Pacific time the next business day. 

(f) Monthly reports shall be available by the sixth (6 ,h ) business day of the 
following month. 

(g) Data extracts for the Agencies shall be available the next business day. 

(h) At a minimum, data shall be uploaded and downloaded every 24 hours. 

(i) Card, application and function blocks, option changes, and revalue information 
shall be downloaded to the Data Acquisition System within twelve (12) hours 
and to the Revalue Network within twenty four (24) hours of recording by the 
clearinghouse system. 
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Change Order No. 10 - Attachment I 


6.II-2.1 Institutional Program Descriptions 
2.1.1 Employer Programs 

Employer programs involve a financial subsidy by employers for travel on one or 
more Agency services by their employees. Three (3) different employer programs 
shall be provided by the Contractor in the RFCS, corresponding to existing 
employer program types as summarized in Figure II-2.1. 


Figure 11-2.1: RFCS Employer Programs 


New RFCS Employer Program Type 

Existing Employer Program Type 

I. Right-to-Ride 

FlexPass 

2. Electronic Voucher 

Commuter Bonus Voucher 

Pre-Paid Pass 

3. Customized Products 

Direct Pass Sales 

Direct Ticket Book Sales 


Travel may be on regular routed service, paratransit, and/or vanpools. For 
vanpools, financial subsidies shall be applied directly to the specific vanpool 
designated by the institution. The Contractor shall coordinate with and report 
vanpool subsidies to the vanpool administrator at the participating Agency(s). 

The Contractor shall also provide options to develop new programs in the future, 
including programs that combine features of those listed in Figure 11-2.1. 


2.1.1.1 Right-to-Ride Pass (e.g. FlexPass) 

The right-to-ride pass shall provide for unlimited use pass privileges by employees 
of an institution on one or more Agency public transportation systems The pass 
privileges will remain in effect until canceled by the employer or Agency. 

Data shall be collected for each pass transaction, and may be used to compute the 
basis for payment by the employer. Survey or other data may also be used to 
determine payment basis. 

The RFCS shall provide two right-to-ride pricing alternatives: 

Flat Rate Pricing. The Agency and employer negotiate a flat rate price for all 
Agency passes (price will vary by Agency), and update the price annually. Data on 
actual use (recorded pass transactions) of Agency services in the previous period is 
used to update the negotiated flat rate price for the following period. 

Per Trip Pricing. The Agency and employer negotiate a price per trip. Employers 
are billed based on the actual use (recorded pass transactions) of the Agency 
service at the agreed per-trip price. 
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2.1.1.2 


Electronic Voucher 


An electronic voucher is the fare card equivalent of the current employer sponsored 
Commuter Bonus Voucher. This program shall provide for a fixed dollar amount 
subsidy to be distributed monthly to participating employees. The subsidy is valid 
for stored value, multi-ride or pass purchase on any Agency public transportation 
service at the discretion of the employee. 

The actual amount of the subsidy shall be configurable by individual employee or 
groups of employees (e.g. one group may receive a $25 subsidy while another may 
receive a $50 subsidy). 

The RFCS shall include the capability of canceling unredeemed vouchers under the 
following circumstances: 

(a) At the direction of the Agencies in the event of non-payment by the 
institution. 

(b) If the voucher has not been redeemed within a period specified by the 
Agencies (e.g. 90 days). In this case, unredeemed value shall be credited to 
the institution account. 


2.1.1.3 Customized Products 

Customized products refers to the loading of a specified pass, multi-ride or stored 
value amount directly to a card or series of cards through any RFCS revalue option. 

An Agency or Institution shall be able to designate (order) the product(s) to be 
loaded, with the card automatically revalued when presented at any revalue point in 
the network. If the product has not been loaded within a period specified by the 
Agencies (e.g. 90 days), the product shall be canceled and unredeemed value 
credited to the institution’s account. 
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Change Order No. 10 - Attachment J 


6.11-2.2.2.3 Customized Product Program (DR 2.03) 


(a) An institution shall be able to order specific RFCS passes, multi-ride or 
stored value amounts for identified cards. 

(b) The RFCS shall automatically load the specified pass, multi-ride or stored 
value amount at any revalue point in the network when the card is 
presented. 

(c) The product shall be applied only once. 

(d) The product shall be canceled and the value credited to the institution 
account if not redeemed within a pre-defined timeframe (variable parameter 
to be determined by the Agencies). 
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Change Order No. 10 - Attachment K 


6.11-4.2.2 Card Information 

(h) Automatic Revalue Information 

i. Revalue threshold 

Period pass - type, validity/activation date, and expiration date 
Multi-ride - type, validity/activation date, and expiration date 
Stored value - dollar amount 

Electronic Voucher - dollar amount 

ii. Credit card account number (not on fare card - only in central 
database) 

iii. Debit card account number (not on fare card - only in central 
database) 

iv. Direct debit bank information (not on fare card - only in central 
database) 

v. Autoload (Electronic Voucher or Customized Product) status - 
pending, loaded, expired (not on fare card - only in central 
database). 

(i) Not Sufficient Funds (NSF) History 

(j) Current Account Balances 

i. Stored value (dollar value with a configurable maximum). The 
Contractor may identify a maximum purse value consistent with 
their business strategy. 

ii. Passes (fixed period [e.g. day pass, weekly pass, two week pass, 
calendar month, etc.] or rolling period [e.g. 7, 14, 28, 30, 90, 365 
days, etc.]) 

iii. Multi-rides (maximum and number remaining, validity period) 
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Change Order No. 10 - Attachment L 

-5.2.3.3 Data Download (From Clearinghouse System) 

(d) The following types of transactions and information flow shall be 
supported: 

i. Function and card blocking and unblocking 

ii. Revalue orders including electronic vouchers or voucher updates, 
and fare products (passes, multi-rides, stored value). 

iii. Fare tables 

iv. Reversals of automatic revalues 

v. Privilege and option changes / cancellations 

vi. Reports 

vii. Transaction logs 

viii. Database off load 

ix. ACH settlement transactions 


Page 28 


Change Order No. 10 - Attachment M 


6.11-9.2 Functional Requirements 

The revalue network and support services shall meet the following functional 
requirements: 

(a) The revalue network as a whole shall cover all types of RFCS revalue functions 
and fare categories, including passes, multi-rides and stored value. 

(b) The revalue network shall permit customers to pay with multiple forms of payment. 
Not all devices are required to support all types of payment, but the revalue 
network as a whole shall support payment by cash, credit, debit, electronic purse, 
and employer program electronic coupon. 

(c) Some or all of the revalue network shall permit customers to check the remaining 
balance on their cards and to view transaction history up to the last 10 transactions. 

(d) The revalue network system and data shall be auditable by independent auditors 
should the Contractor and/or the Agencies deem an audit necessary. 

(e) The Contractor shall train Agency staff in the operation of retail outlet revalue 
devices. Agency staff will be responsible for training retail outlet staff. 
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Change Order No. 10 - Attachment N 


6.11-11.1.6.1 (d) Vanpool Demonstrations - Vanpools equipped with PFTPs 

(d) The Vanpool Demonstration shall test as a minimum: 

i. The use of all pass and stored value fare payment methods accepted 
on fixed route services for vanpool fare payment. Multi-ride will not 
be considered a valid payment for vanpools. 

ii. Fare payment for both regular and infrequent riders. 

iii. Transfers between vans. 

iv. Transfers between vans and fixed route transit services. 

v. The allocation of subsidies for vanpool services and use, including 
subsidized passes and the Electronic Voucher Program. 

vi. Methods for easily downloading transaction data and uploading new 
tables and parameters to the PFTP. 
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Change Order No. 10 - Attachment O 


6.111-9.2 Functional Requirements - Stand-Alone FTP 

(d) SAFTPs supplied for WSF shall be able to conduct fare transactions as follows: 

i. Automatically with no toll booth seller interaction when a card is 
presented and a default fare deducted or pass recorded. 

ii. Through manual fare determination from WSF revenue collection 
(point of sale) system. In this case, the fare will be computed by the 
WSF revenue collection system, with the SAFTP acting as a 
payment acceptance peripheral. Valid pass and multi-ride products 
shall be recognized and applied to the cost of the fare. The 
remaining fare shall be deducted from stored value. 
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Change Order No. 10 - Attachment P 


6.111-10.2.1.2 Card Balance Inquiries 

The response to a “Balance Inquiry” shall display the following information: 


(a) Stored value balance on the card. 

(b) Active passes on the card, by Agency. 

(c) Active Multi-rides on the card, by Agency 


6.111-10.2.1.4 Pass or Multi-Ride Load 

(a) For pass or multi-ride transactions, the customer shall select the Agency and 
desired fare type. 

(b) The device shall read the reduced fare privileges encoded on the card, and 
automatically determine whether a discount is available for the requested 
type of fare at the relevant Agency (e.g. youth monthly pass). 

(c) The device shall display the fare type and value and the customer shall 
select the method of payment. 

(d) The device shall allow a customer to use cash, credit, debit or RFCS smart 
card stored value for pass purchase. 


6.111-10.9 Testing Requirements and Procedures - TVM Integration 


(a) A minimum of 10,000 transactions shall be conducted. 

(b) Transactions shall be divided evenly among all possible card purchase and load 
transactions of which the device is capable. 

(c) The transactions shall also employ all possible payment combinations for a device. 

(d) The stored value amounts, stored pass and multi-ride types and amounts, and fare 
amounts shall be representative of those expected to be employed in the RFCS. 

(e) Detailed information regarding the transaction types, values, and payment methods 
to be used in the cycling test shall be included in the Detailed Test Procedures and 
subject to Contract Administrator approval. 
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Change Order No. 10 - Attachment R 


Exhibit 9 XIII. Clearinghouse Services 

The Transaction Fee is a variable rate for the number of transactions performed each 
month. This fee only includes the variable costs that are incurred in addition to the Fixed 
Monthly Fee. 

There are two types of transaction fees, 1) General, and 2) 3 rd Party Revalue. The “General 
Transactions” consists of E-Purse, Pass and Multi-Ride Payment and Revalue transactions 
and the fee shall be determined according to the total number of transactions generated by 
the Agencies’ transit application (which may include transactions generated by non- 
Agency card acceptors) processed in a month and shall be applied to each such transaction. 
The “3 rd Party Revalue Transaction Fees” shall be those revalue transactions performed 
only through 3 rd party retailers. 

The transaction quantities listed below are for all transactions generated by the Agencies’ 
transit application, which may include transactions generated by non-Agency card 
acceptors. 
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Change Order No. 10 - Attachment S 

6.11-2.2.1 (i) Common Institutional Program Requirements 

i. The Contractor shall provide a single consolidated invoice or billing information 
to a designated Agency for invoicing to the institution as follows: 

i. Payment may be pre- or on a post-usage basis based on monthly, 3 
month, semi-annual, annual, or a combination of these periods at the 
direction of the Agency(s). 

a. Customized programs will require the following payment options: 

1) Electronic Purse (Stored Value) - Pre-payment only 

2) Period Pass - Either pre payment or post payment 

3) Multi-ride -Pre-payment only. 

b) Right to Ride programs with a Flat Rate pricing structure will 
only utilize pre-payment methods. 

c) Electronic voucher programs will only utilize pre-payment 
methods. 

ii. The agencies shall be responsible for flexible billing options that 
allow the institution to pay over time (e.g. partial billing monthly; 
50% @ 30 days, 50% @ 90 days, etc.). 

iii. Billing options shall be at the direction of the Agencies for specific 
institutions. 

iv. The bill shall be broken down by Agency, transaction volume, type 
of transaction, and cost. 

v. A penalty shall be applied by the Agency to any outstanding balance 
due for that invoice. The penalty shall be fixed at a rate not to 
exceed that allowable under State of Washington law. Any payment 
not received by the clearinghouse within thirty (30) days of receipt 
of a billing invoice is past due. 
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CDRL 22 and CDRL 23 Submission Sequencing 
Figure 11-11.6 

Contract Document Requirements List (CDRL) 


CDRL 

Submittal Description 

Reference 

Notes 

1 

Conceptual Design Review 

6.11-11.2.2.1 

6.111- 3.2.0 

6.111- 6.2.2 


2 

Preliminary Design Review 

6.11-11.2.2.2 

6.111- 9.2 

6.111- 1.6.1 

6.111-1.6.2 


3 

Final Design Review 

6.11- 2.2.2.5 

6.11- 11.2.2.3 


4 

Call Center and Internet Standards, Metrics, 
and Reports 

6.11- 1.3.1 

6.11- 1.3.2 


5 

System Backup and Recovery Plan 

6.11- 5.2.8 

6.11- 8.2.3 

6.111- 1.4 

6.111- 3.8 


6 

NSF Plan 

6.11-7.2.1 

(3) 

7 

Revalue Network and Support Services Plan 

6.11-9.3 


8 

Maintenance Plan 

6.11-10.1 

3.1-58.1.3 

(3) 

9 

System Wide Spares Inventory Report 

6.11-10.1 

(1) 

10 

Summary Fault Tracking and Maintenance 
Performance Report 

6.11-10.1 

6.11-11.5.3 

3.1-58 1.4 

(1) 

11 

Telephone Support Procedures and 
Performance Measurements 

6 11-10.2 2 


12 

Telephone Support Statistics Report 

6.11-10.2.2 

(D 

13 

Implementation Plan 

6.11-11.1.1 

6.11-11.1.5 

(2) 

14 

Factory Acceptance Test (FAT) Program 

6.11-11.4.2 

(2) 

15 

Maintainability Test Plan 

6.11-11.4.2.5 

(2) 

16 

System Integration Test Plan 

6.11-11.4.3.1 

(2) 

17 

System Commissioning Plan 

6.11-11.4 5 

(2) 

18 

Beta Test Plan 

6.11-11.4.6.5 

(2) 

19 

Certification of Beta Test Readiness 

6.11-11.4.6.6 

(2) 
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CDRL 


Submittal Description 


Reference 


Notes 


Group 


20 

Failure Review Process 

6.11-11.4.7.1 

(2) 


21 

Acceptance Testing Plan 

6.11-11.4.7.2 

(2) 


22 

Test Procedures 

6.11-11.4.8.1 

(2) 


23 

Overall Inspection and Test Plan 

6.11-11.4.8.2 

(2) 

Group 3 

24 

Test Reports 

6.11-11.4.8.5 

(2) 


25 

Quality Assurance Program 

6.11-11.5 

(2) 


26 

Program Management and Progress Plan 

6.11-11.5 

(2) 


27 

Monthly Progress Reports 

6.11-11.5.2 

(D 


28 

Training Program Plan 

6.11-12.1.1 

(2) 

Group 3 

29 

Training Materials 

6.11-12.3 

(2) 


30 

National Architecture Conformance Plan 

6.111-1.2.2 

(3) 

Group 2 

31 

System Security Plan 

6.111-1.3 


Group 2 

32 

Electromagnetic Compatibility Plan 

6.111-1.7.1 


Group 1 

33 

Required Manuals Schedule 

6.111-1.8.2.1 


Group 3 

34 

System Operations Manual 

6.111-1.8.2.4 

(2) 


35 

System Maintenance Manual 

6.111-1.8.2.5 

(2) 


36 

Required Maintenance Tools 

6.111-1.8.2.5 

(2) 


37 

Software Documentation 

6.111-1.8.2.6 

(2) 


38 

Current Parts List 

6.111-1.8.2.7 

(2) 


39 

System Availability Measurement Plan 

6.111-1.5.2 

(3) 

Group 2 

40 

Non-Fare Applications 

6.111-14.1 


Group 2 

41 

Contract Close-Out Transition Plan 

3.1-85 

(2) (3) 

Group 3 

42 

Baseline Project Schedule 


(2) 



Notes: 

1. Include in monthly or other periodic reports. 

2. CDRL delivery to be coordinated with associated milestone. 

3. CDRL may be submitted with narrative description of purpose at Conceptual Design 
Review. No outline required. The review of such narrative statements shall be 
performed in accordance with Section 3.1-27.5 of the Contract. The acceptance criteria 
shall be that the narrative satisfactorily demonstrates the Contractor’s comprehension of 
the CDRL purpose and the Contractor’s role and responsibilities to perform the work 
required. 
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